home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000023_owner-urn-ietf _Mon Nov 4 12:33:16 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05350 for urn-ietf-out; Mon, 4 Nov 1996 12:33:16 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05345 for <urn-ietf@services.bunyip.com>; Mon, 4 Nov 1996 12:33:14 -0500
  3. Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23964  (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:33:09 -0500
  5. Received: by cs.bu.edu (8.6.10/Spike-2.1)
  6.     id MAA01846; Mon, 4 Nov 1996 12:32:53 -0500
  7. Date: Mon, 4 Nov 1996 12:32:53 -0500
  8. Message-Id: <v02130500aea38e6a4331@[128.148.157.46]>
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="us-ascii"
  11. To: urn-ietf@bunyip.com
  12. From: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand)
  13. Subject: Re: Names and Locations (was [URN] some comments)
  14. Sender: owner-urn-ietf@services.bunyip.com
  15. Precedence: bulk
  16. Reply-To: "David G. Durand" <dgd@cs.bu.edu> (David G. Durand)
  17. Errors-To: owner-urn-ietf@bunyip.com.Another.way.to.see.the.difference.between.URNs.and.URLs.is.to.look.at
  18.  
  19. binding time: a URL has a resolution mechanism defined at the time that it
  20. is created. A URN is explicitly defined to have multiple potential
  21. resolution mechanisms, as long as they work (i.e. lead to right resource).
  22. You can use any kind of indentifier as a URL (even one that was originally
  23. assigned as a URL), but such use implies a contract by the name assigner,
  24. establishes the bounds of variation on the resource (usually, that the
  25. resource be immutable).
  26.  
  27.    URNs are supposed _not_ to have a privileged resolution mechanism, thus
  28. allowing the identifiers to outlive URN resolutin mechanisms. Now, it is
  29. true that we will need to have at least one mechanism for URL resolution,
  30. but the strategy for defining identifiers and that for resolving them
  31. should _not_ be tightly coupled because we _know_ that the mechnisms will
  32. change, but the URNs cannot change.
  33.  
  34.    It is the point of URNs that the _client_ can decide how to resolve
  35. them, while URLs require that the _URL creator_ prescribe how they should
  36. be resolved. That's also why a URN prefix makes URNs more useful, since it
  37. is a tip-off to a client that it may have a choice as to resolution
  38. strategy. It also signals that the assigner of the name claims to meet the
  39. contract for URN persistence. Mixing URN authorities with HTTP protocols is
  40. technically workable, but it makes the deployment of new naming authorities
  41. interact closely with the completely unrelated issue of protocols for HTTP
  42. resolution. It is much simpler to ensure that there is a requirement for
  43. syntactic differentiation of URNs _in contexts where both URLs and URNs can
  44. occur_.
  45.  
  46.    -- David
  47.  
  48. _________________________________________
  49. David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
  50. Boston University Computer Science        \  Sr. Analyst
  51. http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
  52. --------------------------------------------\  http://dynamicDiagrams.com/
  53. MAPA: mapping for the WWW                    \__________________________
  54.  
  55.